A propagation distance issue arises in special deployments where a UE is camped on a faraway cell. The signal strength to the cell is good due special characteristics of the deployment (e.g., sea-reflected signal or certain antenna tilt), but the UL preamble cannot be received correctly by the eNB due to long propagation delay. On the other hand, aggressive RACH issue occurs more in the scenario where the path loss to the cell is low or interference high resulting unsuccessful RACH attempts. These attempts are continued over many seconds as long as a corresponding timer (T300, T310 etc.) expires.
Even though both the propagation distance and Aggressive RACH issues result in excessive load and interference due to repeated random access attempts, these issues are separate and require different solutions. The RAN2 should introduce a solution to the propagation distance issue. However, views on the solutions vary from the UE centric to network centric solution.
As discussed above, the propagation distance issue relates to the scenario where the UE is camped on the cell that is far away. In this case, both UL and DL signal strength can be good. However, because the propagation delay is long, the eNB cannot detect the preamble correctly as the preamble arrives outside the suitable time window. In this regard, in this scenario, an “aliasing problem” can occur where the eNB interprets the preamble incorrectly as a different one as compared to the preamble sent by the UE.
The aliasing problem occurs due to how the preamble sequences are generated. According to 3GPP TS 36.211, multiple random access preambles are generated from one or several Zadoff-Chu sequences. The set of 64 preamble sequences in a cell is found by including the available cyclic shifts from each Zadoff-Chu sequence and adding more Zadoff-Chu sequences as needed. The number of cyclic shifts in a Zadoff-Chu sequence depends on Ncs given by the zero correlation zone configuration and whether unrestricted or restricted sets of cyclic shifts are used.
FIG. 1 shows the detected delay in a PRACH receiver after matched filtering with the root Zadoff-Chu sequence, for unrestricted sets of cyclic shifts and Ncs>0. If the round trip delay is larger than Ncs, the detected delay falls into another preamble sequence. For example, FIG. 1 illustrates that preamble sequence 0 is transmitted, but due to aliasing, this preamble sequence is detected as preamble sequence [Nzc/Ncs]−1. The eNB sends a random access response, however, the UE will not respond with message 3 since the preamble identifier is wrong.
The random access procedure is described in [3GPP TS 36.321]. Briefly, after initialization and resource selection, the UE transmits a preamble on the selected resource. The UE then monitors PDCCH for a Random Access Response (RAR) with a certain RA-RNTI in the RA Response window. If no RAR is received within the RA Response window, or if none of the RARs contain a preamble identifier corresponding to the one transmitted by the UE, the RAR reception is not successful and the UE repeats the preamble transmission until a maximum number of transmissions is reached.
The propagation distance issue can be solved to some extent by existing means. First solution is to apply proper network planning in such a way that the problematic scenarios are avoided. This can be done by tilting antennas, etc. However, this solution is not always a cost effective solution as the cell size may be reduced unnecessarily for the areas where the problem does not occur.
Another solution is to change the PRACH preamble format to and extended format (e.g., preamble format 1 and 3) and zero correlation zone configuration. If this is done, then aliasing problems should be solved in most of the deployments. However, this solution may not be used on all networks and cells as this comes with the cost of radio resources. To conclude, there are existing solutions, but it is not always easy to know when those solutions should be used.
In RAN2, new solution directions have also been proposed. These solutions can be divided to the UE based solutions and network based solutions. A UE based solution can be considered to be a real-time solution whereas a network based solutions is a non-real time solution.
In the UE based solutions, the UE solves the problem situation when the UE cannot connect to the best cell.
In a first solution:                propagation distance issue is addressed in UTRAN and EUTRAN by applying an offset in dB to the current/failed cell in cell selection/reselection criteria.        The offset is applied in UTRAN and EUTRAN when UE detects connection establishment failure one or more times in RRC—number of times is configured by NW.        Offset is cleared upon cell reselection, either to a 3rd cell or to the original cell (using offset) for both UTRAN and EUTRAN. Alternatively, the offset is removed after expiry of a timer.        
In a second solution, when the propagation distance issue is detected by the UE, the cell is barred instead of using an offset. Additionally it has been proposed that the offset is scaled depending on certain conditions.
Additionally, in a solution where the UE detects the propagation distance problem based on the failed RAR messages occurs, if the UE finds that the cell is not congested (e.g. based on lack of back of indicators) and still RAR fails, it can conclude that it suffers from the propagation distance issue.
In a network based solution, the idea is that the network tunes its parameters (such as preamble format) based on the UE assistant information. The solution is not real time as it takes time before the UE can connect to some cell and report the problem. These mechanisms do not need continuous actions from the network and UE side, but can be considered as a long term solution. This solution may be considered that this is simpler and more cost efficient than the UE based solutions.
One solution would be to use MDT or RACH failure reporting to detect the propagation distance problem. Currently, in RRC, there exist rach-Report and ConnEstFailReport. These reports could be used to find out RRC connection failures or RACH failures, which helps then the operator to locate problems and tune the network parameters correctly.
FIG. 2 illustrates an example RACH report format. FIG. 3 illustrates an example ConnEstFailReport format.
As discussed above, even though there are existing solutions, there is no mechanism to identify that the problem exists. Also the solutions proposed has the limitation that there must be a secondary cell that the UE is able to connect to, either based on an offset or by barring the strongest cell. The UE may also cause significant interference if it does not connect to its strongest serving cell.